Distributing software in a global marketplace requires a user interface that is accessible to a variety of users. Generally, an interface is the point at which a connection is made between two elements so that they can work with each other or exchange information. For computer software purposes, an interface is typically software that enables a program to work with the user, another program including an operating system, and the computer's hardware. An interface that enables a program to work with a user is called a user interface and can be a command-line interface, menu-driven, or a graphical user interface.
For example, to facilitate use of the common user interface in different countries/regions, the user interface should support multiple languages. In the simplest form, a software provider can provide multiple-language user interfaces by manually customizing the user interface software code to satisfy the specific language requirements of each supported language. This approach is generally inefficient, however, in that the software provider must maintain separate software code bases for each of the supported languages. Accordingly, the software provider must independently support each separate software code base, such as providing technical support, providing updates, and/or providing patches.
Another approach for facilitating the use of a common user interface in different countries/regions involves providing an operating system with a common user interface software code base in conjunction with various language-specific resource libraries. One such system is Microsoft Corporation's multilingual user interface (“MUI”). Under the MUI approach, the operating system maintains a common user interface code base, a default language resource module, and a number of alternate language-specific resource modules for displaying some or all of the user interface objects in an alternate language. For example, if the user selects Spanish as a desired language, the operating system loads the system resources from a Spanish-specific resource module.
Computer operating systems typically provide a variety of functions to software applications running within the operating system by referring to various resource library files. An operating system often maintains a number of resource modules, with each resource module consisting of resources that are used by the operating system to perform particular tasks. Generally described, a resource is an item of data or code that is shared by multiple programs or in more than one place in a program, such as a dialog box, a sound effect, or a font in a windowed environment. Many features in a program can be altered by adding or replacing resources without modifying the program's source code. Resource data usually consists of the data structures, templates, definition procedures, management routines, icon maps, and so forth associated with a particular resource, such as a menu, window, or dialog box.
In a specific implementation of an MUI-based operating system, the operating system includes a resource loader that obtains and loads resources from the desired language-specific resource module. The resource loader selects between loading resources from a default resource module, typically encoded in English, or from a designated language-specific alternate resource module. Typically, if a desired alternate resource module is unavailable, the resource loader selects the default resource module.
It will be appreciated by one skilled in the relevant art that operating system resource modules may be periodically updated. Typically, the operating system updates are identified by version number that allows for the determination of which updates have been applied. For example, an original operating system resource module may be identified by a version number, such as “version 5.0”. As the operating system resource modules are updated, the updated resource module (which includes resource information) would be labeled “version 5.2.” However, one skilled in the relevant art will appreciate that a resource module update may not necessarily modify the resources contained within the resource. Additionally, because an operating system may utilize a large number of resource modules, most operating system updates are at least initially limited to updating only the version of the default resource modules and not each alternate resource module.
In the above-described example of an MUI-based operating system having a resource loader, the resource loader generally must verify whether a resource to be loaded from an alternate resource module is compatible with the most current version of the operating system. In a conventional MUI-based operating system, this is accomplished by comparing the version information of the alternate resource module with the current version of the operating system. For example, if a resource loader receives a request to load a resource from an alternate resource module having a version label of “3.0”, while the default operating system resource modules have been updated to a version label of “3.3”, the resource loader will not load the resource from the alternate resource module because it assumes that the alternate resource module is not compatible with the current version of the operating system. Thus, the resource loader defaults to loading resources from the updated default resource module. Consequently, the MUI functionality is reduced because the operating system returns to the default language after the upgrade, even though the alternate resource module resources may still be valid.
Accordingly, there exists a need for a system and method to dynamically verify the compatibility of resource modules when operating system upgrades are implemented, for continued MUI functionality.